[% setvar title Kick out all ops - libprt %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Kick out all ops - libprt</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Simon Cozens &lt;<a href='mailto:simon@brecon.co.uk'>simon@brecon.co.uk</a>&gt;
  Date: 25 Sep 2000
  Mailing List: <a href='mailto:perl6-internals@perl.org'>perl6-internals@perl.org</a>
  Number: 315
  Version: 1
  Status: Developing</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>At least for the run time library used by Perl programs, kick all ops
out of core.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>One of the problems with the current Perl compiler is that you have to
carry a Perl run time around with you, and a run time library for the
Perl virtual machine is pretty big, because core's pretty big. So, make
core smaller.</p>
<p>I'd like to extend this also to the whole virtual machine, because, for
instance, there's little point having network stuff in core if you can't
do any networking on your Furby. However, I'm going to restrict the
scope of this RFC to the run time library (let's call it <b><i>libprt</i></b>)
which is used by compiled programs.</p>
<p>So, have <b><i>libprt</i></b> contain little other than the business of setting up
and tearing down the interpreter, plus variable manipulation and scope,
(actually, what's in <b><i>libprt</i></b> is configurable at Perl installation time
- more on that later) and have the byte-compiled program supply the
other ops it needs.</p>
<p>As usual, the interesting bit is how this is done.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>First, arrange our ops into groups; stick all the network functions into
one op group, all the systems functions into another, and so on. As the
compiler comes across an op in the op tree of the program it's
compiling, it'll make a note that the program needs to use the op group
containing that op.</p>
<p>When <b><i>libprt</i></b> is created, the user selects which op groups should
always be present: this is similar to deciding which XS modules should
be statically linked into perl. The compiler checks to see which op
groups a program needs which aren't in <b><i>libprt</i></b>. Depending on what
bytecode looks like, it can either insert something which requests that
op group from a dynamic library when the program is run, or inserts the
object code to implement that op group directly into the output.</p>
<p>This method of auto-detecting necessary op groups might not always work,
notably since <code>eval</code> exists. Hence, the program should be able to
provide compile-time hints to the compiler as to what additional op
groups should be requested:</p>
<pre>    use opgroup 'network';</pre>
<p>will cause the network functions to be loaded in the produced bytecode.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>None.</p>
</div>
